Handling Exceptional Situations in a Warehouse Management

ABSTRACT

The invention provides methods and apparatus, including computer program products, for handling exceptional situations in a warehouse management. From a user application of the warehouse, an exception code is received, the exception code being representative of a predetermined exceptional situation in the warehouse. The exception code is verified as to validity, and if the received exception code is valid, a follow-up action based on the received exception code is automatically triggered.

BACKGROUND OF THE INVENTION

This application relates to handling of exceptional situations in awarehouse management.

STATE OF THE ART

Warehouse management is one of the tasks required in supply chainmanagement. The supply chain, on the other hand, is a network ofretailers, distributors, transporters, warehouses, and suppliers thattake part in the production, delivery, and sale of a product or service.

Warehouse management systems are directed at making optimal use of theresources provided in a warehouse. A computer system keeps real-timetrack of resource use in the warehouse. Usual tasks within the warehouseare managed by transport orders, like the picking, stocking, orreplacing of goods. The person who is actually doing the physicalshifting of goods is provided with a simple order like “pick X goods oftype Y from A and move them to B”.

It is desirable that the warehouse management system has complete andreal-time knowledge of the goods, the flow of the goods, and theresources within the warehouse. This is supported by handheld units (aPDA or the like) for the picking person to receive transport orders orthe like and report their completion. However, due to humans beinginvolved, there will occur situations where the internal representationof the warehouse within the warehouse management system does not matchreality. For example, the picking person receives a transport order topick up 10 goods (usually, handling units) from a specified bin, whichactually is empty.

SUMMARY OF THE INVENTION

It is an object of the present invention to assist to deal withsituations where the internal representation of the warehouse managementsystem does not match reality in a simple and fast way.

In general, in one aspect, this invention provides a method for handlingexceptional situations in a warehouse, the method comprising the stepsof:

-   -   receiving, from a user application of the warehouse, an        exception code, the exception code being representative of a        predetermined exceptional situation in the warehouse;    -   verifying the received exception code as to validity; and    -   if the received exception code is valid, automatic triggering a        follow-up action based on the received exception code.

In an alternative embodiment with a user selection, this inventionprovide a method for handling exceptional situations in a warehouse, themethod comprising the steps of:

-   -   providing a plurality of exception codes to a user application        of the warehouse, each exception code being representative of a        predetermined exceptional situation in the warehouse;    -   receiving, from the user application, a selected one of the        plurality of exception codes; and    -   automatic triggering a follow-up action based on the received        exception code.

Advantageous implementations can include one or more of the followingfeatures.

In an embodiment, the exception code is generated in the userapplication in a first context and the triggered follow-up action isprocessed in a second context. Error detection and the measure for errorhandling can be separated that way.

In an embodiment, the exception code is generated upon detection of anexceptional situation in the warehouse. This special type of exceptionalsituation matches the needs of error handling in a warehouse.

In an embodiment, the plurality of exception codes which are provided tothe user application are dependent on at least one of the type of userapplication, and the profile of a user working with the userapplication. The possible exception handling can be matched to theactual situation and to the competence of the user.

In an embodiment, an exception handling procedure signal is generatedcorresponding to the triggered follow-up action. This signal may be usedfor communication between the first and the second context.

In an embodiment, the user application is part of a product pickingenvironment. This is one of the preferred fields where the invention canadvantageously be used.

In an embodiment, at least one exception code is transmitted via RF.This allows for higher flexibility for the user involved, especially apicker.

In an embodiment, the user application works in an RF environment. Thiseven increases the independence of the user.

In an embodiment, the follow-up action comprises connecting to at leastone of status managing, alert managing, workflow processing systems.These are three important classes of exception handling accommodatingthe possible exceptions that might occur.

In an embodiment, exception handling is encapsulated in the userapplication. This feature provides the advantage of easier integrationinto existing systems.

In an embodiment, a skill level number is assigned to each possiblehandling procedure and the presented and/or selectable possibleexception handling procedures depend on a matching of a predefined skilllevel criterium. Then, the possible exception handling procedures thatare triggered match the competence of the user.

In an embodiment, the skill level numbers represent a hierarchy, and thecriterium is a minimal or a maximal skill level number. This is an easyrepresentation of user competence.

In an embodiment, a number of user profiles is given, the plurality ofexception codes to be provided to the user application is obtained byfilter operation from a data base of exception codes, based on aselected one of the number of user profiles. This is a more involved,but custom-designed and more flexible representation of user competence.

In an embodiment, the plurality of exception codes are transmitted viaRF to a handheld device of the user application. This makes the usermore flexible, and frees the handheld device of too much storage and/orprocessing requirements.

The apparatus of the invention provides similar features and advantages,as are defined by the respective dependent claims.

In particular, the invention comprises also computer systems forperforming the inventive methods.

Furthermore, the invention comprises computer-readable storage mediacomprising program code for performing the inventive methods, whenloaded into a computer system.

One of the advantages is that the present invention allows the user(picking person) to meet the problem of a mismatch between the transportorder and the real situation at once. Without more effort than a userselection, a resolving process is triggered. Moreover, the warehousemanagement system can immediately respond to the inconsistency andupdate its internal representation. Then, the gap between internalrepresentation and reality is kept as small as possible.

BRIEF DESCRIPTION OF DRAWINGS

The invention will be described in detail below with reference to theincluded Drawings and to further features and advantages of theinvention. The Drawings show in

FIG. 1 a design overview of the elements of an embodiment of theinvention;

FIG. 2 an illustrative diagram showing signals exchanged in anembodiment of the invention;

FIG. 3 a flowchart of a method according to an embodiment of theinvention;

FIG. 4 a flowchart of an alternative method according to an embodimentof the invention;

FIG. 5 a flow chart illustrating part of an inventive embodiment wherethe appropriate exception code signals are determined;

FIG. 6 a flow chart illustrating part of an inventive embodiment wherean exception code signal is verified; and

FIG. 7 a flow chart illustrating part of an inventive embodiment wherethe action following reception of an exception code signal is started.

DETAILED DESCRIPTION

FIG. 1 shows elements of an embodiment of the invention in a designoverview. The design is intended to become part of a warehousemanagement system which will not be described in any detail. On theapplication's 10 side, the appropriate response to an exceptionalsituation is selected in communication with a preferably, but notnecessarily encapsulated exception handler 20. The exception handler 20,after having received an exception code in cooperation with application10, may automatically trigger one of the follow-up actions 30.

Here and in the following, an exceptional situation is understood to beany problem stemming from a command given by the warehouse managementsystem to a user that cannot actually be executed. The reason for thisimpossibility is assumed to mainly be an inconsistency of the internalwarehouse representation of the warehouse management system and the realworld. Of course, there are also other possibilities like errors withinthe warehouse management system itself.

The typical example of an exceptional situation is a transport ordergiven to a picking person that cannot be executed. He might be asked topick up a certain number of handling units from a specified bin, whichactually is empty. Or the transport order requests him to store a numberof handling units within a bin without sufficient capacity. Or the binis temporarily inaccessible for any reason. These are only two out of ahuge magnitude of possibilities.

The application 10 may be a picking order management system or the like.As a first additional component according to the invention, the pickingorder management system comprises means 11 that search for exceptionalcodes in combination with exception code filter means 21 of theexception handler 20. Filtering is useful if the concerned pickingperson should not be confronted with all possible exceptions known tothe system. Instead, means 11 and filter 21 provide context-relatedexception codes that may occur in execution of the current transportorder. For example, for the picking person confronted with a bin withoutsufficient capacity to store the handling units as requested anyexception handling related to replenishing of the goods to betransported is of no help at all.

As another additional element the application 10 includes inputtingmeans 12 for an exception code. As it will become more clear afterdescription of embodiments with reference to FIGS. 3 and 4 below, anexception code may be either manually selected by the picking person orautomatically by the application. The inputting means 12 communicatewith means 22 for exception code verification of the exception handler20. Verification of an exception code may be as simple as checkingwhether it is a valid exception code and as complicated as checkingwhether the selected exception code is plausible and assumed to resolvethe problem by the warehouse management system.

Means 13 for processing the exception code within the application 10communicate with means 23 for starting a follow-up action of exceptionhandler 20. Depending on the implemented method, means 13 may request aconfirmation of an exception handling procedure selected by follow-upstarting means 23 of the exception handler 20, or may interactivelyselect an appropriate response to the exceptional situation, as will beexplained below. In a completely automated embodiment, the exceptioncode may be generated by inputting means 12, verified by verificationmeans 22, triggering follow-up means 23 without the processing means 13being involved at all.

In one embodiment, after an exception code is input via inputting means(12), a follow-up action is triggered immediately after the exceptioncode has been verified (22). In an alternative embodiment, a follow-upaction can also be triggered by processing means (13) at a later time,i.e. independent of exception code verification (22).

The exception handler 20 additionally comprises an error handler 24capable of reporting to the application 10 and managing errors thatoccur during the exception handling. Furthermore, a message handler 25is capable of sending messages to the application 10 and receivingmessages from one of the follow-up actions 31, 32, 33.

As can be seen in FIG. 1, three classes of follow-up actions 30 may bediscriminated. Firstly, a status management 31 may be commanded tomodify status variables of the warehouse management objects (Bin,Handling Unit, . . . ). Among the examples for status variables are“damaged” for certain goods, “under construction” for certain parts ofthe warehouse or the like. As can be inferred from the examples, astatus modification does not trigger any action, but modifies theinternal representation of the warehouse management system in order forfuture measures to be informed about the actual situation.

Secondly, the exception code may be transmitted to an alert engine 32where an appropriate alert is raised, which may be a message on asupervisor's display or any other conceivable form of alarm.

Thirdly, a workflow engine 33 may be triggered to start a workflow thatwas assigned and predefined to resolve the problem. This workflow mayrelate to reordering or shifting of goods or any other flow of actions.

Of course, the follow-up action may consist of a combination of thesethree classes. For example, when the workflow engine 33 starts toreorder a good, it can be meaningful to mark the bin as low on stock inthe status management 31 and to send an alert message via alert engine32.

Following the overview description above, further details and variantsof the system will now be described. FIG. 2 shows an explanatory diagramof signals exchanged in an embodiment of the invention. Parts of theapplication 10 may preferably be run on a handheld unit of a pickingperson, like a PDA or a notebook. In order to allow the picking person'sfree action, the handheld is preferably used in an RF environment, i.e.has a wireless connection (dotted lined arrow) to other parts of thewarehouse management system like a server. Nevertheless, it is alsoconceivable to run the application on a stationary computer systemconnected via ethernet or an equivalent (solid lined arrow). Finally,both components may be in use, with part of the application 10, theexception handler 20, and the follow-up components status management 31,alert engine 32, and workflow engine 33 running on a handheld, a PC,and/or a server each.

The grey shaded rectangle shows examples for exception code signals 40exchanged between the application 10 and the error handler 20. Withoutany restrictions implied, each error code is assigned a four-digitnumber. Of course, any other known coding scheme can be used as well.Here, the three classes of follow-up actions are coded in the first twodigits. Codes starting with 25 are alert messages, codes starting with50 are workflows, and codes starting with 75 are status modifications.Again, this is an example and may be exchanged with any other codingscheme.

The meaning of the codes 40 should be clear from their names. Anyway,these are only examples of exception codes that may occur in a warehousemanagement system. Any additional exceptional situation may be includedby assigning an exception code signal and an appropriate statusmodification, alert message, and/or workflow.

FIG. 3 shows a flow chart of a method of an embodiment of the inventionwith interactive selection of an exception code signal. In a first stepS1, a user (normally, but not necessarily a picking person) detects aninconsistency that necessitates exception handling. As alreadydescribed, the inconsistency may relate to a mismatch of the internalwarehouse management system's representation and the actual situation.In any case, the picking person is unable to execute his order becausethe situation makes it impossible. Therefore, he starts the exceptionhandling e.g. by calling the exception handling tool on his handheld. Itshould be repeated that a stationary PC, a notebook or the like can alsobe used.

The means 11 for exception code searching in the application 10determine in a step S2 Systems known unexpected situations that mightoccur in handling of the picking person's current transport order, incooperation with exception code filter 21 of the exception handler 20.Apart from a frontend that necessarily has to be present on the pickingperson's handheld, any of these components may be installed on thehandheld and/or a server accessed via wireless data communication.

In a step S3, the exception handler 20 prepares a list of exceptionhandling procedures for the unexpected situations as determined. Thisprocess can be interactively supported by the input means 12 where thepicking person selects one of the possible unexpected situations priorto selecting any exception handling procedure. In that case,verification means 22 may check the validity and/or plausibility of theexception code corresponding to the selected unexpected situation.

In a step S4, the exception handling procedures are filtered withrespect to the user's skill level. Here, only exception handlingprocedures remain that match the user's profile. As an extreme example,shut down of whole parts of the warehouse due to a detected waterleakage should not be accessible to each of the workers and is removeddue to his profile. On the other hand, the responsible warehouse manageras a user should be able to access all possible exception handlingprocedures.

In a step S5, the subset of exception handling procedures is displayedto the user, preferably by displaying a table within the application 10on the user's handheld. Then, in a step S6, the user selects one of theexception handling procedures. In a step S7, the selected exceptionhandling procedure is communicated to the follow-up starting means 23 ofexception handler 20. The selection process S6, S7 may also beaccompanied by a communication of process means 13 and follow-upstarting means 23, for example determined in a hierarchical sequence ofselections and/or confirmation requests. Moreover, if an error occursduring the procedure, error handler 24 may stop the process and/or starta recovery mechanism.

In a step S8, the exception handler 20 triggers the automatic exceptionhandling according to the selected exception handling procedure. To thatend, follow-up starting means 23 trigger the required functions as afinal step 9 of one of status management 31, alert engine 32, and/orworkflow engine 33. Any response messages of the follow-up applicationsmay be transmitted to the user by message handler 25.

The dotted lined arrows illustrate the flow in case of a variant of theembodiment as described. Here, the alert engine informs a supervisor ofthe user in a step S10 of the selected exception handling procedure.

Then, the supervisor may approve the selected procedure and the methodmay continue with the follow-up action in step S8. On the other hand,the supervisor may disagree. In that case, the method stops. As analternative, the supervisor himself repeats the selection method in astep S11, starting from the display of a subset of possible exceptionhandling procedures in step S4. It should be noted that, with thesupervisor as user, the subset of displayed exception handlingprocedures is different and probably larger than originally. It shouldalso be noted that, in principle, the control loop as described can beiterated with a supervisor of the supervisor, and so on.

FIG. 4 shows a flow chart of an alternative method of an embodiment ofthe invention with automated selection of an exception code signal.Here, the exception code is generated internally in the applicationrather than by input of the user. Variants, however, and detailsdescribed in the context of FIG. 3 can be used in an identical oranalogous way. A combination of interactive and automated selectionaccording to the embodiments described with reference to FIGS. 3 and 4is also possible.

In a first step S101, the application detects an inconsistency andstarts exception handling. The meaning of inconsistency has already beendefined.

In a step S102, known unexpected situations that might occur within theapplication's scope are determined. This can be determined by theapplication alone, or by a combination of search means 11 of theapplication and filter means 21 of the exception handler.

Exception handling procedures for these unexpected situations aredetermined in a step S103. A corresponding exception code signal istransmitted to the exception handler 20 in a step S104, where it isverified and/or checked for plausibility in a step S105. Instead of inthe application alone, steps S103 to S105 can also be processed in acooperation of input means 12 (here, the term “determination means”might be more exact as no user interaction takes place) of theapplication 10 and verification means 22 of exception handler 20.

After verification, in a step S106 the follow-up starting means 23immediately and automatically trigger the appropriate action in at leastone of status management 31, alert engine 32, and/or workflow engine 33(step S107).

Symbolized by dotted lines and arrows, an optional authorisation by asupervisor analogous to the embodiment described with reference to FIG.3 is illustrated. In a step S110, a supervisor is informed of theselected exception handling measure by the alert engine 32. Then, thesupervisor may approve the exception handling procedure, with the methodcontinuing at step S106 triggering the follow-up action. The supervisormay also stop the exception handling procedure, and the methodterminates. Finally, he may decide to reselect the exception handlingprocedure (S111). In that case, the method according to the embodimentas described with reference to FIG. 3 is invoked with the supervisorinteractively selecting an exception handling procedure.

FIGS. 5 to 7 show flow charts of parts of embodiments of the invention.Class definition and the flow of method calls is to be understood as animplementation example and does not restrict the scope of the inventionas described in the more general embodiments above.

FIG. 5 shows a flow chart of a method to get appropriate exceptioncodes. The detailed implementation of FIG. 5 has not necessarily to beused for the above embodiments.

As a first check 200, the availability of the exception instance ischecked. If this is the case, the exception instance is accessed via animported data reference (201). In the other case, the method terminateswith an exception 209 called, for applicant's internal reasons,/SCWM/CX_EXCEPTION. The simple meaning is that no exception handler canbe accessed.

As a second check 202, it is checked whether a data reference to a loginstance is available. If so 203, the log instance is accessed by animported data reference. In the other case 204, a log instance iscreated with a call of the method CREATE_LOG_OBJECT. After steps202-204, it is assured that a valid log instance used to log theexception handling for later reference is present. If no logging isnecessary, these steps 202-204 can, of course, be omitted.

A call 205 of the method SET_EXCEPTION_ATTRIBUTES transfers the currentparameters to the imported instance of the exception handler object (cf.step 200/201). These parameters may include a business context (liketransport order creation, transport order confirmation), the processstep (like moving to bin, picking from bin), the process mode (RF,online, batch), warehouse number, workflow attributes, and more.

Afterwards, by calling 206 FILTER_EXCEPTION_CODES, all appropriateexception codes including a description according to parameters likewarehouse number, business context, and process step are provided.

The call 207 of EXIT->FILTER_DATA is optional and allows tocustom-design the filtering and refine the filtering of step 206.

With a call 208 of SET_EXCEPTION_CODES, the filtered valid exceptioncodes are transferred to the related attribute of the exceptioninstance.

Then, all possible valid and relevant exception codes have beendetermined.

FIG. 6 shows a flow chart of a method to verify exception codes. Thedetailed implementation of FIG. 6 has not necessarily to be used for theabove embodiments.

Steps 200-205 and 209 are identical to the corresponding stepsillustrated in FIG. 5, and a repetition of the description will beomitted. With a call 306 to VERIFY_EXCEPTION_CODES, the importedexception code generated by application 10 will be checked againstentries which are available in customizing a table of valid exceptioncodes. If the exception code is valid at this point of process, avalidation flag will be set. It has already been pointed out that morecomplicated plausibility checks are conceivable at this point. Thisvalidity flag is checked 307.

If the exception code is invalid 308, the method GET_EXCEPTION_CODEaccording to the description with reference to FIG. 5 is called. In theother case 309, a Method GET_FOLLOWUP_CONFIG is called to select theconfiguration data of follow up actions. These follow-up actions may becustomized in advance. If an exception profile is maintained, i.e. ifexception handling procedures are filtered according to the user's skilllevel as described above, and the profile restricts access to specialuser ID's, the follow-up action will be checked against the exceptioncreator, i.e. the person that has triggered the exception handling. Ifno profiles are maintained, all users will have access to all exceptionhandling procedures as a default.

It is checked 310 whether the exception handling procedure should beprocessed. If not, the method terminates. In the other case 311, methodPROCESS_EXCEPTION_CODE is called that will now be described withreference to FIG. 7.

FIG. 7 shows a flow chart of a method to trigger a follow up action. Thedetailed implementation of FIG. 7 has not necessarily to be used for theabove embodiments.

Again, steps 200-204 and 209 are identical to those described above, anda repetition of their explanation will be omitted. In a step 405, anexit instance is created and a method START_ACTION called. This is butan anchor for custom-designed actions and, in a default version, doesnothing.

Then, a method START_STM_PROCESS is called 406. Here, the statusmanagement 301 is requested to perform the required status modification.In case that the status cannot be changed, information of the failurewill preferably be transferred to the application 10 by message handler25.

Afterwards, a method START_WF_PROCESS is called 407 to start a workflowwith help of workflow engine 33. Therein, the workflow environment datais transmitted and the connected workflow is started. Again, messagesrelating to failure or others can be displayed to the user via messagehandler 25 and application 10.

With a call to a method ALERT_WRITE, the appropriate alert messages areselected and prepared to raise an alarm with help of alert engine 32.

It should be noted that any call to one of the follow-up invokingmethods 406-408 may be looped to repeat them from 0 to n times. Asgenerally known, a loop repeated for zero times means that the method isnot called at all. With that mechanism, any combination of statusmodification, workflow, and/or alert may be invoked.

Afterwards, the method PROCESS_EXCEPTION_CODE illustrated in FIG. 7terminates.

With the invention as described above, it is possible to keep the gapbetween real world (physical warehouse) and system data (warehousemanagement system) small at all times. Any detected inconsistency can beentered in the system as soon as possible. With the exception handlingservice, the user is able to describe the problem he has to face byentering the appropriate exception code. With help of that exceptioncode, either automatically or after selection of the user, anappropriate exception handling can be triggered. Different functionslike status management, alerts, or a workflow can be startedimmediately.

The qualified information of the detected inconsistency can be loggedand saved in a database. Therefore, it is possible to monitor and traceall exception information. The exception handler may be encapsulated andwork with the application on the one hand and the follow-up system onthe other with none or only minimal modification of these systems. Theselinkages are configurable to meet the requirements.

The exceptional situation can be solved system-supported. Complexbackground and/or foreground tasks are processed to eliminate thedetected inconsistency. Depending on the user's skill level, the singleexception handling procedures may be only small or of large consequence.In any case, no deeper understanding of the consequences is required,but can optionally be included by a supervisor overriding the system'sdecision.

The present techniques can be implemented in digital electroniccircuitry, or in computer hardware, firmware, software, or incombinations of them. Apparatus of the invention can be implemented in acomputer program product tangibly embodied in a machine-readable storagedevice for execution by a programmable processor. Method steps accordingto the invention can be performed by a programmable processor executinga program of instructions to perform functions of the invention byoperating on the basis of input data, and by generating output data. Theinvention may be implemented in one or several computer programs thatare executable in a programmable system, which includes at least oneprogrammable processor coupled to receive data from, and transmit datato, a storage system, at least one input device, and at least one outputdevice, respectively. Computer programs may be implemented in ahigh-level or object-oriented programming language, and/or in assemblyor machine code. The language or code can be a compiled or interpretedlanguage or code. Processors may include general and special purposemicroprocessors. A processor receives instructions and data frommemories, in particular from read-only memories and/or random accessmemories. A computer may include one or more mass storage devices forstoring data; such devices may include magnetic disks, such as internalhard disks and removable disks; magneto-optical disks; and opticaldisks. Storage devices suitable for tangibly embodying computer programinstructions and data include all forms of non-volatile memory,including by way of example semiconductor memory devices, such as EPROM,EEPROM, and flash memory devices; magnetic disks such as internal harddisks and removable disks; magneto-optical disks; and CD-ROM disks. Anyof the foregoing can be supplemented by or incorporated in ASICs(application-specific integrated circuits).

The computer systems or distributed computer networks as mentioned abovemay be used, for example, for producing goods, delivering parts forassembling products, controlling technical or economical processes, orimplementing telecommunication activities.

To provide for interaction with a user, the invention can be implementedon a computer system having a display device such as a monitor or LCDscreen for displaying information to the user and a keyboard and apointing device such as a mouse or a trackball by which the user canprovide input to the computer system. The computer system can beprogrammed to provide a graphical or text user interface through whichcomputer programs interact with users.

A computer may include a processor, memory coupled to the processor, ahard drive controller, a video controller and an input/output controllercoupled to the processor by a processor bus. The hard drive controlleris coupled to a hard disk drive suitable for storing executable computerprograms, including programs embodying the present technique. The I/Ocontroller is coupled by means of an I/O bus to an I/O interface. TheI/O interface receives and transmits in analogue or digital form over atleast one communication link. Such a communication link may be a seriallink, a parallel link, local area network, or wireless link (e.g. an RFcommunication link). A display is coupled to an interface, which iscoupled to an I/O bus. A keyboard and pointing device are also coupledto the I/O bus. Alternatively, separate buses may be used for thekeyboard pointing device and I/O interface.

1-31. (canceled)
 32. A method for handling exceptional situations in awarehouse, the method comprising: receiving, from a user application ofthe warehouse, an exception code, the exception code beingrepresentative of a predetermined exceptional situation in thewarehouse; verifying the validity of the received exception code; and ifthe received exception code is valid, automatic triggering a follow-upaction based on the received exception code.
 33. The method according toclaim 32, wherein the exception code is generated in the userapplication in a first context and the triggered follow-up action isprocessed in a second context.
 34. The method according to claim 32,wherein the exception code is generated upon detection of an exceptionalsituation in the warehouse.
 35. The method according to claim 32,wherein an exception handling procedure signal is generatedcorresponding to the triggered follow-up action.
 36. The methodaccording to claim 32, wherein the user application is part of a productpicking environment.
 37. The method according to claim 32, wherein atleast one exception code is transmitted via RF.
 38. The method accordingto claim 32, wherein the user application works in an RF environment.39. The method according to claim 32, wherein the follow-up actioncomprises connecting to at least one of status managing, alert managing,workflow processing systems.
 40. The method according to claim 32,wherein exception handling is encapsulated in the user application. 41.The method according to claim 32, wherein a skill level number isassigned to each possible handling procedure and the presented and/orselectable possible exception handling procedures depend on a matchingof a predefined skill level criterium.
 42. The method according to claim41, wherein the skill level numbers represent a hierarchy, and thecriterium is a minimal or a maximal skill level number.
 43. A method forhandling exceptional situations in a warehouse, the method comprising:providing a plurality of exception codes to a user application of thewarehouse, each exception code being representative of a predeterminedexceptional situation in the warehouse; receiving, from the userapplication, a selected one of the plurality of exception codes; andautomatically triggering a follow-up action based on the receivedexception code.
 44. The method according to claim 43, wherein theplurality of exception codes which are provided to the user applicationare dependent on at least one of the type of user application, and theprofile of a user working with the user application.
 45. The methodaccording to claim 43, wherein a number of user profiles is given, theplurality of exception codes to be provided to the user application isobtained by filter operation from a data base of exception codes, basedon a selected one of the number of user profiles.
 46. The methodaccording to claim 43, wherein the plurality of exception codes aretransmitted via RF to a handheld device of the user application.
 47. Anapparatus for handling exceptional situations in a warehouse, theapparatus comprising the steps of: receiving means that receive, from auser application of the warehouse, an exception code, the exception codebeing representative of a predetermined exceptional situation in thewarehouse; verification means that verify the received exception code asto validity; and triggering means that, if the received exception codeis valid, automatically trigger a follow-up action based on the receivedexception code.
 48. The apparatus according to claim 47, wherein theexception code is generated in the user application in a first context(10) and the triggered follow-up action is processed in a second context(20).
 49. The apparatus according to claim 47, further comprisinggenerating means that generate the exception code upon detection of anexceptional situation in the warehouse.
 50. An apparatus for handlingexceptional situations in a warehouse, the apparatus comprising:provision means that provide a plurality of exception codes to a userapplication of the warehouse, each exception code being representativeof a predetermined exceptional situation in the warehouse; receivingmeans that receive, from the user application, a selected one of theplurality of exception codes; and triggering means that automaticallytrigger a follow-up action based on the received exception code.
 51. Theapparatus according to claim 50, wherein the plurality of exceptioncodes which are provided to the user application are dependent on atleast one of the type of user application, and the profile of a userworking with the user application.
 52. The apparatus according to claim50, wherein an exception handling procedure signal is generatedcorresponding to the triggered follow-up action.
 53. The apparatusaccording to claim 50, wherein the user application (10) is part of aproduct picking environment.
 54. The apparatus according to claim 50,further comprising RF means that transmit at least one exception codevia RF.
 55. The apparatus according to claim 50, wherein the userapplication works in an RF environment.
 56. The apparatus according toclaim 50, wherein the follow-up action comprises connecting to at leastone of status managing, alert managing, workflow processing systems. 57.The apparatus according to claim 50, wherein exception handling isencapsulated in the user application.
 58. The apparatus according toclaim 50, wherein a skill level number is assigned to each possiblehandling procedure and the presented and/or selectable possibleexception handling procedures depend on a matching of a predefined skilllevel criterium.
 59. The apparatus according to claim 58, wherein theskill level numbers represent a hierarchy, and the criterium is aminimal or a maximal skill level number.
 60. The apparatus according toclaim 50, wherein a number of user profiles is given, the plurality ofexception codes to be provided to the user application is obtained byfilter operation from a data base of exception codes, based on aselected one of the number of user profiles.
 61. The apparatus accordingto claim 50, wherein the plurality of exception codes are transmittedvia RF to a handheld device of the user application.
 62. A computerreadable medium having program code stored therein that when executed bya processor cause the processor to: determine a possible lot size ofunits with respect to a fixed date for a chain of at least twosequentially dependent process steps, each process step requiring arespective assigned resource by: receiving, from a user application ofthe warehouse, an exception code, the exception code beingrepresentative of a predetermined exceptional situation in thewarehouse; the validity of verifying the received exception code; andautomatically triggering a follow-up action based on the receivedexception code if the received exception code is valid.